\ INTERNAL.TXT  Documentation on the internals of F-PC   by Tom Zimmer


  F-PC is my (Tom Zimmer) latest Forth system of the month. F-PC was built
to handle a class of programming problems that cannot be handled well
on any normal implimentation of Forth because of space constraints.

  F-PC allows the LIST (colon space) segment to be much larger than in
any of my previous Forths.  Strings have also been moved out of
CODE space back into LIST space, which means there is effectively
unlimited space for text messages.  In fact the only real limitation
in size comes from the fact that there are only 64k available for
HEADs.  My calculations indicate there is room for about 3300
definitions on top of the current system of about 2000 words.  This
calculation is based on an average name length of 5 characters, with
an average header length of 12 bytes.  With 5300 total definitions,
less than 30k of CODE space would be used for CODE FIELDS of colon
definitions, leaving the remaining 30+k of CODE space for variables
and arrays.  Not an infinitely large application obviously but
probably large enough for most (99%) applications.

  F-PC places a segment (ES) and and offset (IP) on the return stack
for each nest operation. Only the starting RELATIVE segment is
compiled into the CODE FIELD, and the conversion to absolute segment
is performed by NEST.  This makes the code fully relocatable as is
required by the DOS environment.  Some performance could be gained by
using absolute segment addressing, and performing a conversion at
save and load time to and from relative and absolute, but I have not
done this, and don't plan to for now.  The performance gain would
come from having a simpler NEST, what would not need to perform the
relative to absolute conversion at runtime.  This system looses about
20% in nest/unnest performance due exclusively to that conversion.

  CS and DS always point to the CODE space, and so all assembly
language operations work with data in the CODE segment unless a
special operator like @L or !L is used to reach an external memory
area.  This means there is no penalty to be paid for most Forth
operations.

 05/19/88 22:03
        Fixed a potentially dangerous bug in FSAVE, there was only
        32 bytes of stack space allocated in the .EXE file to be
        available at boot time, and under some conditions some of
        the code was getting over written. I have changed the
        allocation to be 255 bytes. This seems to work OK!